The logic in this Apply function can be simplified. The current structure with multiple if statements and return points can be condensed into a single conditional check, which improves readability and reduces complexity.

	if !thinking.IsUserDefinedModel(modelInfo) && modelInfo.Thinking == nil {
		return body, nil
	}
	return applyMiniMax(body, config), nil

Thanks for the suggestion! Simplified the conditionals into a single check in 3e4482c.

The applyMiniMax function can be refactored for better clarity by reusing the body variable instead of introducing a new result variable. This makes the data flow more straightforward and the code more concise.

	reasoningSplit := configToBoolean(config)

	if len(body) == 0 || !gjson.ValidBytes(body) {
		body = []byte(`{}`)
	}

	// Remove any OpenAI-style reasoning_effort that may have been set
	body, _ = sjson.DeleteBytes(body, "reasoning_effort")
	body, _ = sjson.SetBytes(body, "reasoning_split", reasoningSplit)

	return body

Good catch — refactored to reuse body directly in 3e4482c.

Register MiniMax in static model registry

Adding a minimax section in models.json is not sufficient because internal/registry/model_definitions.go still does not define or traverse a minimax field in staticModelsJSON, GetStaticModelDefinitionsByChannel, or LookupStaticModelInfo; the new entries are therefore dropped on unmarshal and never found by lookup. In practice, LookupModelInfo(model, "minimax") returns nil for these models, so MiniMax requests are treated as user-defined and bypass the capability metadata/validation this commit is trying to introduce.

Useful? React with 👍 / 👎.

Great catch! Fixed in 3e4482c — added MiniMax field to staticModelsJSON, GetMiniMaxModels() getter, case "minimax" in GetStaticModelDefinitionsByChannel, and data.MiniMax to LookupStaticModelInfo.

Parse OpenAI Responses thinking for MiniMax

The MiniMax branch only falls back to extractOpenAIConfig, which reads reasoning_effort, but OpenAI Responses requests use reasoning.effort (the openai-response shape used by /responses/compact in OpenAICompatExecutor.Execute). In that path, extractThinkingConfig returns empty, hasThinkingConfig is false, and the MiniMax applier is never invoked, so reasoning_split is not produced and MiniMax-specific thinking support silently does nothing for responses traffic.

Useful? React with 👍 / 👎.

Reuse static MiniMax metadata for compat models

When MiniMax is configured through the new openai-compatibility example, sdk/cliproxy/service.go:955-970 still registers compat.Models as UserDefined: true without copying any Thinking support, and registry.LookupModelInfo prefers that dynamic entry over the static minimax definitions (internal/registry/model_registry.go:173-176). So this new provider-key override still sends MiniMax-M2.7 down the applyUserDefinedModel path, meaning the levels/capabilities added in models.json are never used for the advertised config path and MiniMax requests keep bypassing validation/clamping.

Useful? React with 👍 / 👎.

Drop Responses reasoning fields before setting reasoning_split

/responses/compact traffic stays in the openai-response schema, and the translator returns the raw payload when source and target are both openai-response (sdk/translator/registry.go:43-52). For requests that reach this applier via a thinking suffix, an existing reasoning.effort object therefore survives because this code only deletes top-level reasoning_effort. The forwarded MiniMax request can end up carrying both reasoning_split and the stale OpenAI Responses reasoning block, which is a schema mismatch specific to compact/Responses callers.

Useful? React with 👍 / 👎.